1. The Field of the Invention
The present invention relates generally to interfacing communication applications with hardware devices in a computer operating system. More specifically, the present invention relates to interfacing a standard single port communication application to multiple ports without requiring modification to the single port communication application.
2. The Relevant Technology
Typical computer software applications that interface with external hardware devices such as modems, printers, wireless transceivers, as well as other imaginable devices heretofore have been explicitly programmed to interface via a single interface port from the communication application to the target hardware device via an operating system. Many such communication applications have proliferated and have become uniquely successful in their target markets. To appreciate the advances of the present invention, it is necessary to understand how port devices are supported under modern commonplace operating systems. In the present description, an exemplary operating system, such as the Microsoft.RTM. Windows '95.RTM. and Windows '98.RTM. operating systems are discussed. These exemplary operating systems, among others, provide support for communications hardware through the architecture described in FIG. 1. In FIG. 1, the dotted line depicted as boundary 106 represents a protection interface provided by the operating system in conjunction with the microprocessor of the computing platform. Those familiar with the art of structured programming appreciate that applications and higher level drivers operate in the ring 3 area 114, while the operating system and lower level device drivers execute in ring 0 area 116. A communication application 100 provides control of a hardware device 112 through an application programming interface (API) which, in the exemplary operating system, consists of a 16 or a 32-bit application function call through the Wirlbox Win32 APIs of the Microsoft operating system. Functions performed through the API include configuring the device, reading data from the device or writing data to the device. Such API function calls 118 are handled by a software component, COMM.DRV 104 which, in FIG. 1, is depicted as a ring 3 device driver.
COMM.DRV device driver 104 passes the application function calls through the ring 3/ring 0 boundary 106 interface to another software module resident within the operating system known as VCOMM 108 using a VCOMM API 120. VCOMM 108 is a ring 0 device driver that manages all port drivers registered in the operating system. Among other things, VCOMM 108 manages the loading and unloading of port drivers, determines which port driver should handle function calls received through VCOMM API 120 and passes function calls to the appropriate driver for completion of the procedure.
A port driver 110 thereafter handles the details of completing function calls received from VCOMM 108 for a specific hardware device. In the present exemplary operating system (e.g., Windows '95 and Windows '98) such operating systems include port drivers for devices that communicate through serial ports (e.g., SERIAL.VXD) and parallel ports (e.g., LPT.VXD). For hardware devices 112 that deviate from such hardware interfaces, a compatible port driver must be developed and registered with the operating system for interfacing between VCOMM 108 and hardware 112.
While most communication applications have heretofore communicated directly with a single identified hardware device via a specific compatible port driver, technological advances have enabled communication data to be delivered to and propagated over various hardware configurations that may, for among various reasons, present a preferable hardware medium. For example, traditional computer-to-computer communications have taken place via hardware devices known as modems. A data-generating communication application originates data which is passed down through a device driver and ultimately a modem-compatible port driver for propagation across a physical medium such as a telephone line to a symmetrical receiving computer architecture. While the telephone line conduit provides a preferred interconnection in one case, other interconnection techniques may also provide a favorable channel in other applications. For example, in contrast to a modem operating as the hardware device for communicating over the telephone line, a wireless transceiver having internal modulation capabilities may also be employed for a wireless hardware device application. In such a configuration, a separate port driver compatible with the interactive interface of the wireless transceiver must be substituted for the modem-compatible port driver forming the above-described communication channel.
For such a wireless transceiver configuration, the communication application must be customized to interface with a wireless port driver. Such a menu of hardware devices requires that established communication applications be rewritten at great expense to accommodate each additionally discovered hardware device.
It would represent an advancement in the art to provide a method and system for interfacing a software communication application having a single port interface with a plurality of hardware devices without requiring the modification of the port interface of the communication application. It would further represent an advancement in the art to provide a method and system for enabling a user of a communication application to interact with the communication application in a consistent manner while relying upon the sophistication of the operating system and its associated components and drivers to carry out the requested data exchange over at least one of a plurality of hardware devices without requiring any modifications to the communication application or additional attention by the communication application user.